Verify a Cloudinary media url is our asset, not just a Cloudinary url - #185

…nary url (#185)"

This reverts commit 525b38c.

Photo upload has been failing with Invalid Signature. The server signed four
parameters; Cloudinary verifies three.

Cloudinary signs only the upload parameters it recognises and silently drops
the rest. max_file_size is not one it recognises, so including it in the signed
set produced a signature that could never match. Its own error said so — the
String to sign it echoed back listed folder, timestamp and upload_preset, and
nothing else.

This is not a regression from #185, which never touched media.ts or the client
upload path. It dates from whenever max_file_size entered the signature and has
been broken ever since; nobody noticed because nobody had uploaded a photo
through the UI in between.

The comment above the limits is what caused this. It claimed they were
"enforced on the signature itself so a leaked signature can't be reused to
upload a bigger file than we allow" — a reasonable-sounding guarantee that
Cloudinary does not offer. Replaced with what is actually true: the limits are
advisory, they exist to feed the client-side check, and the only enforceable
ceiling is whatever the petnote_image_signed / petnote_video_signed upload
presets have configured in the Cloudinary console.

The client stops sending max_file_size too. Cloudinary ignores it, so it bought
nothing except the appearance that the limit was being transmitted somewhere
meaningful. The size check that produces a useful error before a doomed upload
stays, and the callable still returns maxFileSize to feed it.

Two tests encoded the same false premise and are corrected. One of them —
"signs exactly the parameters it returns" — already carried the comment "if the
handler ever signs a different set of params than it hands back, Cloudinary
rejects every upload". It was right, and it still passed, because it recomputed
the same wrong set the handler used. max_file_size was on both sides of that
comparison and on neither side of Cloudinary's. Its list is now written as the
contract with Cloudinary rather than a mirror of the implementation.

NOT VERIFIED HERE: whether the upload presets actually carry a max file size in
the Cloudinary console. I cannot read that from the repo. If no limit is set
there, then after this change there is no server-side size ceiling at all —
only the advisory client check.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

…a Cloudinary url (#185)"" (#188)

This reverts commit 72c8efe.

The cloud name is the first path segment of every image URL the app serves. It
is public by construction — anyone who has loaded a single photo already has
it — and storing it in Secret Manager protected nothing.

What it did instead was invent a failure mode. Because it was a secret param,
every callable that validates a media URL had to remember
`secrets: [CLOUDINARY_CLOUD_NAME]`, and one that forgot would pass CI and throw
in production on the first upload. CI cannot catch that: the emulator drives
handlers through .run(), which bypasses secret mounting entirely, and setup.ts
set the variable directly, so the tests saw a value the deployed function would
not have had. #185's own description flagged this and had to derive the list of
eleven bindings by grepping call paths rather than by testing it.

All eleven bindings are gone. The value lives in platform.ts next to
CLOUDINARY_FOLDER, and shared.ts reads it directly instead of reaching into
process.env — which also removes the "misconfigured" branch that existed only
to handle a caller arriving without the binding. There is no longer a way to
arrive without it.

CLOUDINARY_API_KEY and CLOUDINARY_API_SECRET stay in Secret Manager. Those are
the credentials, and media.ts keeps binding them. The truthiness check there
now covers only those two, since the cloud name cannot be empty.

setup.ts stops setting CLOUDINARY_CLOUD_NAME, and the tests compare against the
constant. That is the part that matters beyond tidiness: a test can no longer
pass because the environment supplied something production would not have.

Functions 80/80, build / lint / typecheck:test clean.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

The cloud name is the first path segment of every image URL the app serves. It
is public by construction — anyone who has loaded a single photo already has
it — and storing it in Secret Manager protected nothing.

What it did instead was invent a failure mode. Because it was a secret param,
every callable that validates a media URL had to remember
`secrets: [CLOUDINARY_CLOUD_NAME]`, and one that forgot would pass CI and throw
in production on the first upload. CI cannot catch that: the emulator drives
handlers through .run(), which bypasses secret mounting entirely, and setup.ts
set the variable directly, so the tests saw a value the deployed function would
not have had. #185's own description flagged this and had to derive the list of
eleven bindings by grepping call paths rather than by testing it.

All eleven bindings are gone. The value lives in platform.ts next to
CLOUDINARY_FOLDER, and shared.ts reads it directly instead of reaching into
process.env — which also removes the "misconfigured" branch that existed only
to handle a caller arriving without the binding. There is no longer a way to
arrive without it.

CLOUDINARY_API_KEY and CLOUDINARY_API_SECRET stay in Secret Manager. Those are
the credentials, and media.ts keeps binding them. The truthiness check there
now covers only those two, since the cloud name cannot be empty.

setup.ts stops setting CLOUDINARY_CLOUD_NAME, and the tests compare against the
constant. That is the part that matters beyond tidiness: a test can no longer
pass because the environment supplied something production would not have.

Functions 80/80, build / lint / typecheck:test clean.

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>